Graphical modeling environments are programs that enable a user to construct and analyze a model of a process or system. Examples of graphical modeling tools include time-based block diagrams, such as Simulink from The MathWorks Inc., state-based and flow diagrams, such as those found within Stateflow® also available from The MathWorks, Inc., data-flow diagrams, such as LabVIEW, available from National Instruments Corporation, and software diagrams and other graphical programming environments, such as Unified Modeling Language (UML) diagrams.
Time-based block diagrams, which are an example of a type of graphical modeling environment, are software packages that enable a user to model, simulate, and analyze dynamic systems i.e., systems whose outputs change over time, and generate a program corresponding to the system. Time-based block diagrams environments can be used to explore the behavior of a wide range of real-world dynamic systems, including electrical circuits, shock absorbers, braking systems, and many other electrical, mechanical, and thermodynamic systems.
Simulating a dynamic system in a time-based block diagram is typically a two-step process. First, a user creates a graphical model, such as a block diagram, of the system to be simulated. A graphical model may be created using a graphical user interface, such as a graphical model editor. The graphical model depicts time-based relationships between the systems inputs, states, parameters and outputs. After creation of the graphical model, the behavior of the dynamic system over a specified time period is simulated using the information entered into the graphical model. In this step, the graphical model is used to compute and trace the temporal evolution of the dynamic systems' outputs (“execute” the graphical model), and automatically produce either deployable software systems or descriptions of hardware systems that mimic the behavior of either the entire model or portions of the model (code generation).
Block diagrams are an example of graphical models created within a graphical modeling environment, such as a time-based block diagram, for modeling a dynamic system. A block diagram model of a dynamic system is represented schematically as a collection of nodes interconnected by lines, which represent logical connections between the nodes. Signals correspond to the time-varying quantities represented by each line connection and are assumed to have values at each time instant. Each node may represent an elemental dynamic system, and the relationships between signals and state variables are defined by sets of equations represented by the nodes. Inherent in the definition is the notion of parameters, which are the coefficients of the equations. These equations define a relationship between the input signals, output signals, state, and time, so that each line represents the input and/or output of an associated elemental dynamic system. A line emanating at one node and terminating at another signifies that the output of the first node is an input to the second node. Each distinct input or output on a node is referred to as a port. The source node of a signal writes to the signal at a given time instant when its system equations are solved. The destination node of this signal read from the signal when their system equations are being solved. Those skilled in the art will recognize that the term “nodes” does not refer exclusively to elemental dynamic systems but may also include other modeling elements that aid in readability and modularity of block diagrams.
For example, in Simulink®, an example of a time-based block diagram from The Math Works Inc., a model of a dynamic system is a block diagram comprising a plurality of nodes, called blocks, which are interconnected by lines that represent signals. In Simulink®, each block represents a functional entity, such as an elementary dynamic system, which implements a mathematical operation, i.e., an algorithm or equation, on the data being processed by the system represented by the block diagram. Each block produces an output either continuously (a continuous block) or at specific points in time (a discrete block). The type of the block determines the relationship between a block's outputs and its inputs, states, and time. A block diagram can contain any number of instances of any type of block needed to model a system. The signals in a block diagram model represent a time-varying quantity that is updated, i.e. read-by and written-to, by the blocks. Simulink® and other software products for modeling a dynamic system provide a graphical user interface (GUI) for building models of dynamic systems as block diagrams. Each block diagram may be built by dragging and dropping blocks provided in pre-defined blocksets or custom developed by the user.
After creation of the graphical model, such as a block diagram, representing the dynamic system, the user simulates the behavior of the system over a specified time span. The information entered into a model is used to perform the simulation and a processor solves the equations defined by the nodes in the simulated model to produce simulation results. Alternatively, the processor converts the graphical model to executable code. Automatic code generation is a process whereby software is automatically produced from a graphical model of a dynamic system. The software produced may be compiled, then executed on a digital computer, implementing the functionality specified by the model.
The solution (computation of system response) of a graphical model, such as a block diagram, is obtained by evaluating the relationship between the signals and state variables representative of a dynamic system over time, where time starts at a user-specified “start time” and ends at a user-specified “stop time”. Each evaluation of these relationships is referred to as a time step. The signals in the graphical model represent quantities that change over time, and these quantities are defined for all points in time between the start and stop time during execution of the graphical model.
In Simulink® and other graphical modeling environments, the nodes, blocks or other model components used to model a dynamic system are generally either “virtual”, meaning the blocks play no active role in a simulation or “nonvirtual”, meaning the blocks play an active role in simulating a system represented by the graphical model. Virtual blocks are merely used to organize a graphical model graphically, while nonvirtual blocks represent elementary dynamic systems that affect the model's behavior. A virtual block is provided for graphical organizational convenience and plays no role in the definition of the system of equations described by the block diagram model. The signals of a block diagram are also generally either “virtual” or “nonvirtual”.
In large graphical models, there may be an extensive set of lines that connect one section of the model to another section. Virtual blocks, such as a bus creator block and a bus selector block reduce block diagram clutter by managing groups of signals as a “bundle”, known as a bus signal, to improve the readability of models. In the current state of the art, the bus signal comprises a collection of signals grouped together as a collection of logical signals, i.e., by name. The virtual bus creator blocks help bundle a number of signals together to form a single bus signal. This single bus signal then connects the two sections of the model. At the destination end of the bus signal, a virtual bus selector block helps un-bundle the individual signals so that they can be connected to other blocks.
Currently, bus signals have no specification and merely a comprise a visual grouping of signals for simplifying the appearance of a block diagram or other graphical model. To simulate an operation on signals in a bus signal having different data types, the signals must be de-grouped prior to passing each signal separately through a non-virtual block representing an operation to be performed on the signal. Furthermore, in current time-based block diagrams and other graphical modeling systems, some nodes or blocks impose restrictions on the attributes of the signals they can handle, and some nodes or blocks, such as a unit-delay block in Simulink® and Stateflow blocks, do not accept bus signals, meaning that the bus signal must be decomposed before passing the signals contained therein through the blocks in the graphical model.